[2025-11-27] MITMPROXY 작동 방식

🦥 본문

작동 방식

Explicit HTTP

클라이언트가 프록시 서버의 주소와 포트 번호를 직접 지정하여 사용하는 방식.

GET http://example.com/index.html HTTP/1.1

Explicit HTTPS

클라이언트가 프록시 서버의 주소와 포트 번호를 직접 지정하여 HTTPS을 통해 보내는 방식.

• 복호화

  mitimproxy는 중간에서 양쪽 트래픽을 디코딩하여 읽음.이 과정에서 클라이언트가 CA를 읽을 때, 신뢰할 수 없는 CA이거나 서버의 정보와 일치하지 않으면, 클라이언트의 연결을 끊고 통신을 거부해야 함. 그래서 mitmproxy는 클라이언트가 서버에 요청을 할 때 가짜 인증서를 즉석에서 생성. 그리고 이 인증서는 자체 CA가 서명한 것이기 때문에, 미리 등록을 해야 함.

• 도메인 이름

  HTTPS로 통신을 할 때, 클라이언트는 인증서에 적힌 도메인 이름과 자신이 접속하려던 도메인 이름을 확인. 하지만 IP주소로 접속할 때, mitmproxy는 IP 주소만 알게 되어 인증서에 IP 주소만 쓰고 연결을 거부당할 수 있음

  • 동작 흐름
    1. 클라이언트의 CONNECT 수신
    2. mitmproxy가 해당 IP 주소와 연결 시도
    3. TLS 핸드셰이크를 통해 서버의 인증서를 받음
    4. 인증서에서 도메인 이름을 추출하여 가짜 인증서 생성 후 클라이언트와 통신

• SAN

  IP 주소가 아닌 SAN(Subject Alternative Name)을 통해 클라이언트가 접속하는 경우에도, 인증서에서 추출 후 가짜 인증서에 추가함

• SNI(Server Name Indication)

  하나의 웹 서버에서 여러 개의 도메인을 운영할 때, TLS는 하나의 IP 주소당 하나의 인증서만 지원하는 제약에 의해 모든 도메인에 HTTPS를 적용할 수 없음

  SNI : TLS 프로토콜의 확장 기능. 클라이언트가 TLS 핸드셰이크를 시작하는 초기에 자신이 접속하려는 원격 서버의 도메인 이름을 서버에 알림. 서버는 SNI 값을 확인하고 도메인 이름에 맞는 정확한 인증서를 선택하여 전송

  클라이언트가 IP 주소만 알려줄 때, SNI를 모르기 때문에 기본 인증서를 받는 데, 이는 클라이언트가 접속하려는 도메인과 다름

  • 동작 흐름
    1. 접속 시도할 때, 클라이언트가 SNI를 전달할 때까지 TLS 핸드셰이크를 허용
    2. 전달되면 클라이언트와 대화 일시 중지
    3. SNI를 통해 정확한 인증서를 얻고 가짜 인증서를 만듦

• 전체 동작 흐름

1. 클라이언트가 프록시에 연결 후 HTTPS 연결 터널을 만들자는 HTTP CONNECT 요청을 보냄
2. 응답
3. TLS 핸드셰이크를 시작, SNI를 알려줌
4. 프록시 역시 서버와 SNI를 사용하여 TLS 핸드셰이크를 함
5. CN과 SAN이 담긴 인증서를 보냄
6. 가짜 인증서를 생성하고 클라이언트와 중지 했던 TLS 핸드셰이크를 완수
7. 요청과 응답이 프록시를 거쳐감

Transparent HTTP

클라이언트의 설정 변경 없이 네트워크 계층에서 연결이 프록시로 리디렉션됨.

• 추가 요소

  1. 리디렉션 매커니즘

     인터넷상의 서버로 보내는 TCP 연결을 투명하게 가로채서 프록시 서버로 향하게 하는 장치. 특정 포트로 가는 패킷을 프록시 서버의 리스닝 포트로 강제로 돌림

  2. 원본 목적지 조회 모듈

     리디렉션을 수행한 메커니즘은 원래 목적지 주소를 기록해둠. 프록시는 해당 매커니즘(방화벽)으로부터 조회 가능

• 동작 흐름
  1. 클라이언트가 서버에 연결 시도.
  2. 라우터가 연결을 가로채 mitmproxy가 수신 대기중인 로컬 포트로 강제로 리디렉션
  3. mitmproxy는 요청을 받고 router와 통신하여 원래 목적지 주소를 알아냄.
  4. HTTP 요청 응답을 주고 받음

Transparent HTTPS

ClientHello 메시지를 찾아 감지하여 HTTPS임을 식별. 이전의 Transparent HTTPd와 Explicit HTTPS 결합

1. 연결 시도
2. 리디렉션 후 원래 목적지 알아냄
3. SNI를 사용하여 TLS 핸드셰이크
4. SNI를 사용하여 서버와 TLS 핸드셰이크
5. CN&SAN이 담긴 인증서를 받음
6. 가짜 인증서를 생성 후 클라이언트와 TLS 핸드셰이크를 마침
7. 요청 응답을 주고 받음